IBIS Macromodel Task Group Meeting date: 03 March 2015 Members (asterisk for those attending): Altera: David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy eASIC Marc Kowalski SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad: Walter will be presenting. - Michael Mirmak requested some time too. - Randy: I could speak about the C_comp subcircuit. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Walter and Randy produce C_comp BIRD. - Randy: We have been discussing this. - Arpad to review IBIS specification for min max issues. - In progress. ------------- New Discussion: AMI Direction: - Michael M showed IBIS-AMI and Direction Indication - slide 4: - Michael M: This has been updated with comments from last week and other conversations. - This is about algorithmic direction. - Also checking that the right analog model is used. - slide 5: - Michael M: AMI_Model_Type and AMI_Model_Direction - Type is the capability. - Direction is the current state. - Arpad: On slide 4 I think they are combinable. - slide 6: - Michael M: The question is whether to have one DLL or multiple. - Another question is how selection would work. - The analog model enable pin should also connect to algorithmic. - Not everyone will want to write a single multi-state DLL, #1. - Approach #2 uses multiple algorithmic model keywords. - Fangyi: This is about putting the TX and RX in one file? - Michael M: This is needed for memory IP, DDR4 for example. - We can support something like the syntax we have today. - Walter: IBIS can handle handle the step response at the pad. - The equalization is different for TX and RX. - Memory designers might not want to implement it. - There would be separate simulations for each direction. - Ambrish: The question here is about having one model or two. - Walter: #2 has separate algorithmic models for each direction. - Michael M: There is no intent to support switching on the fly. - Fangyi: The idea is to use a compounded model. - Michael M: We will not force a DLL to be both TX and RX. - We do not want to make it illegal either. - That is handled by AMI_Model_Direction I/O - slide 8: - Fangyi: These would be new Reserved Parameters. - Michael M: We have to be sure TX parameters are not sent into an RX. - Walter: We do not need direction. - There could be an RX model and a TX model. - Michael M: Direction is not needed for a TX-only or RX-only model. - Only the I/O is different. - Walter: Isn't this redundant with Model_type? - Michael M: Do we limit at the model level? - The state has to be below the model level. - Fangyi: Two parameters are needed. - For a combined model the DLL will need an indicator. - It would be an AMI parameter. - Walter: That is AMI_Model_Direction. - Fangyi: The other one is needed to know which one to load if it is split. - Michael M: Direction must be indicated if it is I/O. - Fangyi: Can we enforce that the model has two DLLs? - Walter: We will need to know which parameters are TX and RX. - There could be one DLL but two AMI files. AR: Michael M send AMI Direction presentation to Mike L for posting Normative and Informative - Walter showed a presentation Normative and Informative - slides 2-5: - Walter: For example I proposed a change having to do with redrivers and channels. - slide 6: - Walter: Normative is the correct way to do something. - Informative is just information. - Examples should be considered informative. - slides 7-8: - Walter: We have no indication if a TX will modify its EQ based on input. - Our reference flows are really only informative. - The syntax and input/output parts are normative. - slide 9: - Walter: These things are all informative. - Arpad: What is it when we have an option, when you can do one thing or another? - Walter: We can use models in ways outside the flows. - Arpad: That raises a question if it is a valid flow. - Walter: It's valid, it just doesn't have to be used. - Arpad: If a model uses a flow and gets incorrect results the flow is not informative. - Bob: Flows in 6.0 are the expected flows, which model makers need to know. - Walter: Tools still do not have to use those flows. - Bob: There might be less accurate results. - Walter: One question is which C_comp to use for generating tables. - That is informative. - [Corner C_comp] is normative. - We need to understand what in our specification is normative and informative. - slide 10: - Walter: Here is a list of things that are normative and informative. - Mike L: It would be interesting to see the specification with only normative portions. - Arpad: We have learned over time how to write a specification. - In general we should distinguish options and call mistakes informative. C_comp circuits: - Randy drew on the whiteboard. - Randy: One question is where on a buffer it is important to look at signal quality. - It could be Si_Location. - For an input we need to look at the input buffer. - There can be a low pass filter effect from the interconnect from pad to buffer. - We might want a C_comp model to have a terminal for that. - Walter: For timing you would want an unnamed node in C_comp. - Nodes on the left side hook to the legacy buffer. - We already have that probe point in our model. - A probe point between two series resistors would be new. - Arpad: I would put two models together, each with their own on-die interconnect. - Radek: Randy is suggesting separating internal nodes. - Randy: Yes. - Walter: The top one here is a tri-state, the bottom is an input. - They each have their own V-T curves. - This is two buffers, it looks like [External Circuit]. - John: Do we want only one buffer behind each pin? - Randy: This is a DQ buffer. - The input is always isolated from the driver by a resistor. - Arpad: Is this one or two buffers? - Randy: One buffer but with an extra port to look at it. - Randy showed the IBIS 6 specification page 103. - Randy: This is like my concept. - I want to probe at "my receive" - Walter: On the whiteboard, can one determine the voltage between the buffers? - We don't know where all of the currents are going. - In SPICE the square would be Z. - This is not a simple problem. - How important is it? - Randy: We want to look at it all the time. - Walter: I-V curves are at the square and include the resistor already. - Randy: Maybe we could just designate that the probe point is in another place. - Bob: A [Model Selector] could be used. - Arpad: It could be done with an external circuit. - Maybe not the current specification, but with new interconnect BIRDs. - Bob: The 200 ohm R and C complicates it. - Randy: The C currently is lumped into C_comp. AR: Randy send whiteboard circuit diagram to Mike for posting. Next week: ------------- Next meeting: 10 Mar 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives